docs: name the API resource recipient links (?link=) - #69

Background

SimplePDF renamed the public prefill resource to recipient links (simple-pdf #603 / #605), now in production (release 6f020890, 2026-11-14): the API serves /documents/{document_id}/recipient_links and /documents/{document_id}/recipient_links/{recipient_link_id} (checked against the production OpenAPI spec), /prefills no longer exists, and a document link carries ?link=<id> instead of ?prefill=<id>. This repository's docs, the React example and the build-with-simplepdf agent skill still send integrators and agents to the old names.

Changes

• The build-with-simplepdf skill names the resource recipient links: POST /documents/{document_id}/recipient_links (what a recipient link is), the delete path, and the storage and server-side resource lists
• The Copilot reference app (copilot/, private) and its README pass a document link with ?link= instead of ?prefill=
• The embed tests use ?link= in the document URLs they pass through
• The contract pin re-syncs to the live editor (editor_version 6f020890): one description changes (a document with more form fields than a document can is a load failure); the generated types are unchanged. main would fail the same check today
• The @simplepdf/embed README and mount.ts example name both ids (documents/<document_id>?link=<recipient_link_id>)
• A patch changeset for @simplepdf/embed, so its npm README stops showing ?prefill=

Notes

• Release cascade: @simplepdf/react-embed-pdf and @simplepdf/web-embed-pdf pin @simplepdf/embed exactly, so the embed patch also publishes react 1.14.1 and web 1.10.1 ("Updated dependencies"), with no change to built code. An empty changeset instead would publish nothing and leave the npm README showing ?prefill= until the next release.
• Review: cold review 8/10; fixed: the changeset reads as one sentence in the repo's release style and no longer claims a change the package does not ship; the documents URL examples name both ids; this description names the Copilot app.